Closes #730

The asymmetry

The decoder has been bounded at JSON_MAX_DEPTH since #495. The encoder walked the Value graph with no counter and no cycle check — and a Value graph can contain cycles; the cycle collector exists because it can.

d is {"x": 1}
dict_set of [d, "self", d]
try:
    print of (json_encode of d)
catch e:
    print of f"caught {e}"

Pre-fix: Segmentation fault (core dumped), rc=139. The catch is useless — try/catch does nothing against a SIGSEGV. print already handled cycles, which is what made json_encode the surprise. append of [a, a] builds one by accident.

Both directions now share one constant (hoisted above the encoder rather than duplicated), so a document that decodes always re-encodes. Exceeding it raises a catchable EK_VALUE rather than emitting truncated JSON — silent truncation would be the exact silent-wrong-answer class this audit is closing.

Why a parameter, not a counter

The decoder tracks depth in g_json_depth, a field on the execution state. That is safe there because there is no early return between its ++ and --. This encoder signals failure by returning -1 up through every frame — precisely the shape where a counter gets skewed by one missed decrement. And a skewed counter fails the next call, not the one that broke it. A parameter cannot leak, and needed no new state field or bridge macro.

Reachability

Beyond json_encode itself: json_path, and — the serious one — shared_set. An HTTP handler storing a self-referential value took the whole server down.

eigs_json_encode now returns NULL on refusal and both ext_http.c callers check it. They previously strlen'd the result unconditionally, so returning NULL without touching them would have traded a stack overflow for a NULL deref. shared_incr needed a mutex unlock on its new early return.

Tests

Extends test_json_depth.eigs (3 → 9 checks), the file that already owns the decoder half:

• cyclic dict raises
• cyclic list (append of [a, a]) raises
• over-deep non-cyclic (300) raises
• CONTROL: a 151-deep value still encodes (exact length 303) and decodes back — without this a bound of 1 would pass every raise-check above
• round-trip proving the two limits agree

Pre-fix the section exits 139 (SIGSEGV); post-fix 0.

Validation

• Release 3268/3268
• asan-http + detect_leaks=1: 3363/3363, leak tally 0
• embed_stack_soak.sh (64 KiB rlimit): PASS
• -fstack-usage: 80 B/frame → ~16 KiB above baseline at the limit, vs the decoder's 96 B/frame at the same depth

Follow-up filed separately

Profiling the stack cost turned up something bigger that is not addressed here: under a 64 KiB stack the process SIGSEGVs at ~40–60 source nesting levels, so PARSE_MAX_DEPTH (256) is unreachable there — the stack dies before the guard can fire. Filing separately rather than changing a limit inside a JSON PR.

🤖 Generated with Claude Code